home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 92mar / area.security.92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  7.9 KB  |  187 lines
  1.  
  2. Security Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o Steve Crocker:  crocker@tis.com
  8.  
  9.  
  10. Area Summary reported by Steve Crocker
  11.  
  12. The Security Area within the IETF is responsible for development of
  13. security oriented protocols, security review of RFCs, development of
  14. candidate policies, and review of operational security on the Internet.
  15.  
  16. Much of the work of the Security Area is performed in coordination with
  17. working groups in other areas.  The Security Area Advisory Group (SAAG)
  18. is a group of security experts which provides both consulting help to
  19. other areas and direct management of working groups within the Security
  20. Area.
  21.  
  22. The main bulk of work for the SAAG consists of a set of formal work
  23. items.  These work items correspond to four types of activities.
  24.  
  25.  
  26.   1. Working groups within the IETF Security area.  These are marked as
  27.      ``Security.''
  28.   2. Working groups in allied organizations that function as part of the
  29.      IETF Security area.  These are marked either ``PSRG'' for the
  30.      Privacy and Security Research Group, or ``TSIG'' for working groups
  31.      within the Trusted Systems Interoperability Group.
  32.   3. Security relevant developments within working groups in areas other
  33.      than security.  These are marked according to the relevant area,
  34.      viz., Applications, Internet Services, Management, OSI, Operations,
  35.      Routing, Standards, or User Services.
  36.   4. Internal SAAG work items.  These are topics which do not merit the
  37.      creation of a formal working group but which do need some level of
  38.      attention.  These are assigned to a SAAG member and followed for
  39.      one or more SAAG meetings.  These are marked as ``SAAG''.
  40.  
  41.  
  42. The SAAG met during the first and last working group period of the San
  43. Diego IETF. The first meeting was used to coordinate the activities for
  44. the week and the second meeting was used to report on the activities
  45. that have occurred.
  46.  
  47. During the week, of the twenty-two open work items on Monday, two work
  48. items were closed and two new work items were opened.  The key
  49. activities for the week to report are working groups and work items in
  50. the security area:  SNMP Security, Common Authentication Technology,
  51. Privacy Enhanced Mail, RFC 931 Revision, and Architectural Discussions.
  52.  
  53.  
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61. SNMP Security Working Group (SNMPSEC)
  62.  
  63. There were three documents, published in January 1992, which are
  64. currently under consideration by the IAB.
  65.  
  66. Common Authentication Technology Working Group (CAT)
  67.  
  68. The basic idea is you have a set of applications that want access to one
  69. or more authentication mechanisms, for example Kerberos or the
  70. Distributed Authentication Security Service (DASS). There is a common
  71. program interface, a General Security Services Application Program
  72. Interface (GSS-API), that has been defined such that these applications
  73. can be written to be neutral with respect to which mechanism is actually
  74. employed.  The binding with a mechanism takes place at some later time,
  75. currently compile time.  This raises the question of how two
  76. applications each bound to a different mechanism would interoperate.  In
  77. particular, if one peer supported Kerberos and the other peer DASS,
  78. would they be able to authenticate each other?
  79.  
  80. This question was the principal focus of the meetings during this week.
  81. Although the GSS-API was not designed with hybrid/common mechanism in
  82. mind, it was discovered that it would support such an objective through
  83. a number of different technical solutions.  Most of the meeting time
  84. this week was spent identifying the requirements of a solution.  It is
  85. believed that the objective is both technically feasible and achievable.
  86.  
  87. Privacy Enhanced Mail Working Group (PEM)
  88.  
  89. The specification of the key management infrastructure has been the
  90. principal source of controversy during the last few meetings.  A revised
  91. document was prepared and distributed prior to this meeting, and was
  92. well received during this meeting.  Along with the three other documents
  93. associated with PEM (Message Encryption and Authentication Procedures;
  94. Algorithms, Modes and Identifiers; Key Certification and Related
  95. Services), it will be submitted to the IESG by June in hopes of
  96. achieving publication as a Proposed Standard by the Boston IETF.
  97.  
  98. The publication of the documents stabilizes the specifications and sets
  99. the stage for the deployment of the Internet reference implementation of
  100. PEM. A set of action items predicating the deployment of PEM were
  101. identified and assigned.  These items include establishing the necessary
  102. database mechanisms and software at the Internet Certification Authority
  103. (ICA) for resolving distinguished name conflicts (this is necessary in
  104. the absence of Directory Services), drafting an agreement to be used
  105. between the ICA and the Policy Certification Authorities (PCA), and
  106. facilitating the creation of PCAs (only one PCA proposal has been
  107. submitted to the ICA for review; others are expected soon).  All of
  108. these items are non-technical and do not effect the publication of the
  109. specifications nor Beta testing the deployment of PEM, which is expected
  110. to begin soon.
  111.  
  112.  
  113.  
  114.                                    2
  115.  
  116.  
  117.  
  118.  
  119.  
  120. RFC 931 Revision
  121.  
  122. RFC 931 is a specification of a protocol for a receiving peer of TCP
  123. connection request to ask a server on the originating host of the
  124. originating peer for an identifier associated with the originator of the
  125. request.  The identifier would typically be the login name of the user
  126. initiating the request.  This protocol was called an authentication
  127. server.  As far as security is concerned, the value returned by the
  128. server is only meaningful in the context of that host, and is
  129. informational only since there are no assurances that a valid value is
  130. being returned.
  131.  
  132. There is an effort to revise the document to tighten up the syntax of
  133. the protocol and put it on the standards track.  In addition, a public
  134. domain implementation exists that is currently being used by a modest
  135. number of sites.
  136.  
  137. Previously this effort was being led by Dan Bernstein, the author of the
  138. revised document and the implementation.  In order to give the protocol
  139. the discussion it needs the effort has been restructured and a working
  140. group created with Mike St.  Johns as the Chair, the author of the
  141. original RFC 931.  In addition the revised protocol has been renamed to
  142. be called the Identity Server to better reflect its functionality.
  143.  
  144. Architectural Discussions
  145.  
  146. The SAAG in its two meetings spent a significant about of time
  147. discussing a security architecture for the Internet.  Since the Privacy
  148. and Security Research Group (PSRG) is currently addressing the long-term
  149. objective(s) in this area, the majority of the discussion focussed on
  150. what the SAAG role could be in this area.
  151.  
  152. A number of action items were identified as a result of these
  153. discussions.  First, Barbara Fraser from the CERT has agreed to draft a
  154. document identifying some near-term security goals that the IETF, in
  155. particular the SAAG, could be concerned about.  This will help to focus
  156. SAAG discussions and guide interactions with working groups in other
  157. areas.  We expect to have the document in time for discussions at the
  158. Boston IETF SAAG meeting.
  159.  
  160. Second, two Birds of a Feather sessions will be scheduled at the Boston
  161. IETF. One will be for Lower Layer Security and it will probably focus on
  162. IP layer authentication and encryption, although some discussion about
  163. the OSI TLSP and NLSP, and the SDNS SP3 and SP4 is expected.
  164.  
  165. The other BOF will be to discuss access control.  Given the existence of
  166. authentication, in particular the strong authentication work of the CAT
  167. Working Group, the next question is what to do with the knowledge that
  168. you know who your peer is.
  169.  
  170. Finally, the routing area has received very little attention from
  171. security to date.  With all of the activity in routing it has become
  172. essential that the Security Area become much more directly involved.
  173.  
  174.                                    3
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Radia Perlman will be the liaison to the SAAG for the routing area.  We
  181. will be discussing a routing area security plan during our Boston
  182. meeting.
  183.  
  184.  
  185.  
  186.                                    4
  187.